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Abstract 


This document describes an Extensible Provisioning Protocol (EPP) 
extension mapping for the provisioning and management of E.164 
numbers that represent domain names stored in a shared central 
repository. Specified in XML, this mapping extends the EPP domain 
name mapping to provide additional features required for the 
provisioning of E.164 numbers. 
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1. Introduction 


This document describes an E.164 number mapping for version 1.0 of 
the Extensible Provisioning Protocol (EPP). This mapping, an 
extension of the domain name mapping described in [1], is specified 
using the Extensible Markup Language (XML) 1.0, as described in [2], 
and XML Schema notation, as described in [3] and [4]. 


The EPP core protocol specification [5] provides a complete 
description of EPP command and response structures. A thorough 
understanding of the base protocol specification is necessary to 
understand the mapping described in this document. 
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ENUM [6] describes how the Domain Name System (DNS) can be used to 
identify services associated with an E.164 number. The EPP mapping 
described in this document specifies a mechanism for the provisioning 
and management of E.164 numbers stored in a shared central 
repository. Information exchanged via this mapping can be extracted 
from the repository and used to publish DNS resource records as 
described in ENUM [6]. Examples used in this document were chosen 
specifically to illustrate provisioning concepts for the example 
resource records described in the ENUM specification. 


1.1. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [7]. 


In examples, "C:" represents lines sent by a protocol client, and 
"S:" represents lines returned by a protocol server. Indentation and 
white space in examples are only provided to illustrate element 
relationships and are not a REQUIRED feature of this specification. 


XML is case sensitive. Unless stated otherwise, XML specifications 
and examples provided in this document MUST be interpreted in the 
character case presented to develop a conforming implementation. 


2. Object Attributes 


This extension adds elements to the EPP domain name mapping [1]. 
Only new element descriptions are described here. 


2.1. E.164 Domain Names 


An E.164 domain name is a representation of an E.164 number that has 
been translated to conform to domain name syntax, as described in the 
ENUM specification [6]. The labels used to describe the name space 
of an E.164 domain name are a policy matter that is beyond the scope 
of this document. 


2.2. NAPTR Fields 


According to ENUM [6], Naming Authority Pointer (NAPTR) resource 
records are used to identify available ways for contacting a specific 
node identified by a domain name created from the translation of an 
E.164 number. The basic NAPTR record format is described in RFC 3403 
[8]. Rules for structuring and using NAPTR records for use with ENUM 
are described in RFC 3761 [6]. 
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Several NAPTR field values are optional per RFC 3403. RFC 3761 
describes processing rules that require the presence of certain NAPTR 
field values. This document describes field value requirements that 
correspond to RFC 3761. 

2.2.1. Order 


The NAPTR order field, a 16-bit unsigned integer, is represented in 
this mapping using the XML Schema "unsignedShort" data type. 


2.2.2. Preference 


The NAPTR preference field, a 16-bit unsigned integer, is represented 
in this mapping using the XML Schema "unsignedShort" data type. 


2.2.3. Flags 


The NAPTR flags field is represented in this mapping using a single 
character. The case of the flag character is not significant. 


2.2.4. Service 
The NAPTR service field is represented in this mapping using a 
character string with an unspecified maximum length. Valid values 
are application-dependent. 

2.2.5. Regular Expression 
The NAPTR regexp field is represented in this mapping using a 
character string with an unspecified maximum length. This field can 
contain numerous backslashes and should thus be treated with care. 

2.2.6. Replacement 
The NAPTR replacement field, whose value is a domain name, is 
represented in this mapping using a character string with a maximum 
length of 255 characters. 

3. EPP Command Mapping 
A detailed description of the EPP syntax and semantics can be found 
in the EPP core protocol specification [5]. The command mappings 


described here are specifically for use in implementing ENUM 
provisioning processes via EPP. 
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3.1. EPP Query Commands 


EPP provides three commands to retrieve object information: <check> 
to determine if an object is known to the server, <info> to retrieve 
detailed information associated with an object, and <transfer> to 
retrieve object transfer status information. 


3.1.1. EPP <check> Command 


This extension does not add any elements to the EPP <check> command 
or <check> response described in the EPP domain mapping [1]. 


3.1.2. EPP <info> Command 


This extension does not add any elements to the EPP <info> command 
described in the EPP domain mapping [1]. Additional elements are 
defined for the <info> response. 


When an <info> command has been processed successfully, the EPP 
<resData> element MUST contain child elements as described in the EPP 
domain mapping [1]. In addition, the EPP <extension> element MUST 
contain a child <el164:infData> element that identifies the extension 
namespace and the location of the extension schema. The <el64: 
infData> element contains one or more <elé64:naptr> elements that 
contain the following child elements: 


An <el64:order> element that contains a NAPTR order value. 
- An <el64:pref> element that contains a NAPTR preference value. 


- An OPTIONAL <el64:flags> element that contains a NAPTR flags 
value. 


- An <el64:svc> element that contains a NAPTR service value. 


- An OPTIONAL <el164:regex> element that contains a NAPTR regular 
expression value. 


— An OPTIONAL <el164:replacement> element that contains a NAPTR 
replacement value. 
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Example <info> response: 


S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 

S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 

S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
epp-1.0.xsd"> 

<response> 

<result code="1000"> 
<msg>Command completed successfully</msg> 
</result> 
<resData> 
<domain:infData 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 
domain-1.0.xsd"> 
<domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name> 
<domain: roid>EXAMPLE1—-REP</domain: roid> 
<domain:status s="ok"/> 
<domain: registrant>jd1234</domain:registrant> 
<domain:contact type="admin">sh8013</domain:contact> 
<domain:contact type="tech">sh8013</domain:contact> 
<domain:ns> 
<domain:hostObj>nsl.example.com</domain:hostObj> 
<domain:hostObj>ns2.example.com</domain:hostObj> 
</domain:ns> 
<domain:host>nsl.example.com</domain:host> 
<domain:host>ns2.example.com</domain:host> 
<domain:clID>ClientX</domain:clID> 
<domain:crID>ClientY</domain:crID> 
<domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> 
<domain:upID>ClientX</domain:upID> 
<domain:upDate>1999-12-03T09:00:00.0Z2</domain:upDate> 
<domain:exDate>2005-04-03T22:00:00.0Z2</domain:exDate> 
<domain:trDate>2000-04-08T09:00:00.02</domain:trDate> 
<domain:authInfo> 
<domain: pw>2fooBAR</domain: pw> 
</domain:authInfo> 
</domain:infData> 
</resData> 
<extension> 
<el64:infData xmlins:e164="urn:ietf:params:xml:ns:el64epp-1.0" 
xsi:schemaLocation="urn:ietf:params:xml:ns:el64epp-1.0 
elé64epp-1.0.xsd"> 
<el164:naptr> 
<el64:order>10</el164:order> 
<e164:pref>100</el64:pref> 
<e164:flags>u</el64:flags> 
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S: <e164:svc>E2U+sip</e164:svc> 

SÉ <el64:regex>"!*.*S!sip:info@example.com!"</el64:regex> 
S: </el64:naptr> 

S: <el64:naptr> 

S: <e164:order>10</e164:o0order> 

S: <e164:pref>102</el64:pref> 

Ss <e164:flags>u</el64:flags> 

S: <e164:svc>E2U+msg</el64:svc> 

S: <el64:regex>"!*.*$!mailto:info@example.com!"</el64:regex> 
S: </el64:naptr> 

S: </e164:infData> 

S: </extension> 

S: <trID> 

S: <cl1TRID>ABC-12345</c1TRID> 

SE <svTRID>54322-XYZ</svTRID> 

S: </trID> 

S: </response> 

S:</epp> 


An EPP error response MUST be returned if an extended <info> command 
can not be processed for any reason. 


3.1.3. EPP <transfer> Command 


This extension does not add any elements to the EPP <transfer> 
command or <transfer> response described in the EPP domain mapping 
[1]. 


3.2. EPP Transform Commands 


EPP provides five commands to transform objects: <create> to create 
an instance of an object, <delete> to delete an instance of an 
object, <renew> to extend the validity period of an object, 
<transfer> to manage object sponsorship changes, and <update> to 
change information associated with an object. 


3.2.1. EPP <create> Command 


This extension defines additional elements for the EPP <create> 
command described in the EPP domain mapping [1]. No additional 
elements are defined for the EPP <create> response. 


The EPP <create> command provides a transform operation that allows a 
client to create a domain object. In addition to the EPP command 
elements described in the EPP domain mapping [1], the command MUST 
contain an <extension> element. The <extension> element MUST contain 
a child <el64:create> element that identifies the extension namespace 
and the location of the extension schema. The <el64:create> element 
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contains one or more <elé6é4:naptr> elements that contain the following 
child elements: 

- An <el64:order> element that contains a NAPTR order value. 
- An <el64:pref> element that contains a NAPTR preference value. 


— An OPTIONAL <el164:flags> element that contains a NAPTR flags 
value. 


- An <el64:svc> element that contains a NAPTR service value. 


- An OPTIONAL <el164:regex> element that contains a NAPTR regular 
expression value. 


- An OPTIONAL <e164:replacement> element that contains a NAPTR 
replacement value. 


Example <create> command: 


:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
epp-1.0.xsd"> 
<command> 
<create> 
<domain:create 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 
domain-1.0.xsd"> 
<domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name> 
<domain:period unit="y">2</domain:period> 
<domain:ns> 
<domain:hostObj>nsl.example.com</domain:hostObj> 
<domain:hostObj>ns2.example.com</domain:hostObj> 
</domain:ns> 
<domain: registrant>jd1234</domain:registrant> 
<domain:contact type="admin">sh8013</domain: contact> 
<domain:contact type="tech">sh8013</domain:contact> 
<domain:authInfo> 
<domain: pw>2fooBAR</domain: pw> 
</domain:authInfo> 
</domain:create> 
</create> 
<extension> 
<el64:create 
xmlns:e164="urn:ietf:params:xml:ns:elé64epp-1.0" 


OQ: ACO E EE ECH, EK ECH, Or, Or) ACO, OO QAO: OO ELE 
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xsi:schemaLocation="urn:ietf:params:xml:ns:el64epp-1.0 

elé64epp-1.0.xsd"> 

<el64:naptr> 
<e164:order>10</el164:order> 
<e164:pref>100</el64:pref> 
<e164:flags>u</el64:flags> 
<el64:svc>E2U+sip</el64:svc> 
<el64:regex>"!*.*$!sip:info@example.com!"</el64:regex> 

</el64:naptr> 

<el164:naptr> 
<e164:order>10</el64:order> 
<el164:pref>102</el64:pref> 
<e164:flags>u</el64:flags> 
<el64:svc>E2U+msg</el64:svc> 
<el64:regex>"!*.*$!mailto:info@example.com!"</el64:regex> 

</el164:naptr> 

</e164:create> 
</extension> 
<clTRID>ABC-12345</cl1TRID> 
</command> 
:</epp> 


@r OK. @:QO OO: O61: ALO OG OOO: OQ 


When an extended <create> command has been processed successfully, 
the EPP response is as described in the EPP domain mapping [1]. 


3.2.2. EPP <delete> Command 


This extension does not add any elements to the EPP <delete> command 
or <delete> response described in the EPP domain mapping [1]. 


3.2.3. EPP <renew> Command 


This extension does not add any elements to the EPP <renew> command 
or <renew> response described in the EPP domain mapping [1]. 


3.2.4. EPP <transfer> Command 
This extension does not add any elements to the EPP <transfer> 
command or <transfer> response described in the EPP domain mapping 
[1]. 

3.2.5. EPP <update> Command 
This extension defines additional elements for the EPP <update> 


command described in the EPP domain mapping [1]. No additional 
elements are defined for the EPP <update> response. 
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The EPP <update> command provides a transform operation that allows a 


client to change the state of a domain object. In addition to the 
EPP command elements described in the EPP domain mapping [1], the 
<update> command MUST contain an <extension> element. The 


<extension> element MUST contain a child <el64:update> element that 
identifies the extension namespace and the location of the extension 
schema. The <el64:update> element contains one or more <el64:add> or 
<el64:rem> elements. Each <el64:add> and <el64:rem> element contains 
an <el64:naptr> element that contains the following child elements: 


An <el64:order> element that contains a NAPTR order value. 
- An <el64:pref> element that contains a NAPTR preference value. 


- An OPTIONAL <el64:flags> element that contains a NAPTR flags 
value. 


- An <el64:svc> element that contains a NAPTR service value. 


- An OPTIONAL <el164:regex> element that contains a NAPTR regular 
expression value. 


- An OPTIONAL <e164:replacement> element that contains a NAPTR 
replacement value. 


Example <update> command: 


C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 

E xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
C xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 

G epp-1.0.xsd"> 

C: <command> 

C <update> 

Cc <domain:update 

C xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 

E xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 
a domain-1.0.xsd"> 

C <domain:name>3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa</domain:name> 
C </domain:update> 

Ç </update> 

C <extension> 

G <elé64:update xmlns:e164="urn:ietf:params:xml:ns:el64epp-1.0" 
C xsi:schemaLocation="urn:ietf:params:xml:ns:el64epp-1.0 
C el64epp-1.0.xsd"> 

C <e164:rem> 

C <el1l64:naptr> 

C <el64:order>10</el64:order> 
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Ce <e164:pref>102</el64:pref> 
C: <e164:flags>u</el64:flags> 
Ck <e164:svc>E2U+msg</el64:svce> 
C: <el64:regex>"!*.*$!mailto:info@example.com!"</el64:regex> 
Gs </el64:naptr> 

Gs </el164:rem> 

G: </e164:update> 

Cs </extension> 

Gs <clTRID>ABC-12345</cl1TRID> 

C: </command> 

C:</epp> 


When an extended <update> command has been processed successfully, 
the EPP response is as described in the EPP domain mapping [1]. 


4. Formal Syntax 


An EPP object mapping is specified in XML Schema notation. The 
formal syntax presented here is a complete schema representation of 
the object mapping suitable for automated validation of EPP XML 
instances. The BEGIN and END tags are not part of the schema; they 
are used to note the beginning and ending of the schema for URI 
registration purposes. 


BEGIN 
<?xml version="1.0" encoding="UTF-8"?> 


<schema targetNamespace="urn:ietf:params:xml:ns:el64epp-1.0" 
xmilns:e164="urn:ietf:params:xml:ns:elé4epp-1.0" 
xmlns="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified"> 


<annotation> 
<documentation> 
Extensible Provisioning Protocol v1.0 
domain name extension schema for E.164 number provisioning. 
</documentation> 
</annotation> 


KIS 

Child elements found in EPP commands. 

--> 
<element name="create" type="el64:createType"/> 
<element name="update" type="el64:updateType"/> 
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<= 
Global elements. 
--> 
<element name="naptr" type="el64:naptrType"/> 


<a 
Child elements of the <create> command. 
--> 
<complexType name="createType"> 
<sequence> 
<element ref="el64:naptr" maxOccurs="unbounded"/> 
</sequence> 
</complexType> 


<complexType name="naptrType"> 
<sequence> 
<element name="order" type="unsignedShort"/> 
<element name="pref" type="unsignedShort"/> 
<element name="flags" type="el64:flagsType" 
minOccurs="0"/> 
<element name="svc" type="el64:svcType"/> 
<element name="regex" type="el64:regexType" 
minOccurs="0"/> 
<element name="repl" type="el64:replType" 
minOccurs="0"/> 
</sequence> 
</complexType> 


<simpleType name="flagsType"> 
<restriction base="token"> 
<pattern value=" [A-Z] | [a-z] | [0-9] "/> 
<length value="1"/> 
</restriction> 
</simpleType> 


<simpleType name="svcType"> 
<restriction base="token"> 
<minLength value="1"/> 
</restriction> 
</simpleType> 


<simpleType name="regexType"> 
<restriction base="token"> 
<minLength value="1"/> 
</restriction> 
</simpleType> 
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<simpleType name="replType"> 

<restriction base="token"> 
<minLength value="1"/> 

<maxLength value="255"/> 


</restriction> 
</simpleType> 
= 
Child elements of the <update> command. 
--> 
<complexType name="updateType"> 
<sequence> 
<element name="add" type="el164:addRemType" 
minOccurs="0"/> 
<element name="rem" type="e164:addRemType" 
minOccurs="0"/> 
</sequence> 
</complexType> 
<= 
Data elements that can be added or removed. 
--> 
<complexType name="addRemType"> 
<sequence> 
<element ref="el64:naptr" maxOccurs="unbounded"/> 
</sequence> 
</complexType> 
<!-- 
Child response elements. 
--> 


<element name="infData" type="el64:infDataType"/> 


he 
<info> response elements. 
--> 
<complexType name="infDataType"> 
<sequence> 


<element ref="el64:naptr" maxOccurs="unbounded"/> 


</sequence> 
</complexType> 


Sea 

End of schema. 
--> 

</schema> 

END 
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5. Internationalization Considerations 
EPP is represented in XML, which provides native support for encoding 
information using the Unicode character set and its more compact 
representations, including UTF-8 [10]. Conformant XML processors 
recognize both UTF-8 and UTF-16 [11]. Though XML includes provisions 
to identify and use other character encodings through use of an 
"encoding" attribute in an <?xml?> declaration, use of UTF-8 is 
RECOMMENDED in environments where parser encoding support 
incompatibility exists. 
As an extension of the EPP domain mapping [1], the elements, element 
content, attributes, and attribute values described in this document 
MUST inherit the internationalization conventions used to represent 
higher-layer domain and core protocol structures present in an XML 
instance that includes this extension. 

6. IANA Considerations 


This document uses URNs to describe XML namespaces and XML schemas 
conforming to a registry mechanism described in RFC 3688 [9]. Two 
URI assignments have been completed by the IANA: 
Registration for the extension namespace: 

URI: urn:ietf:params:xml:ns:el64epp-1.0 

Registrant Contact: IESG 

XML: None. Namespace URIs do not represent an XML specification. 
Registration for the extension XML schema: 

URI: urn:ietf:params:xml:schema:el164epp-1.0 

Registrant Contact: IESG 

XML: See the "Formal Syntax" section of this document. 


7. Security Considerations 


The mapping extensions described in this document do not provide any 
security services beyond those described by EPP [5], the EPP domain 


name mapping [1], and protocol layers used by EPP. Security 
considerations related to ENUM are described in the "Security 
Considerations" section of the ENUM specification [6]; security 


considerations related to the Dynamic Delegation Discovery System and 
NAPTR records are described in the "Security Considerations" section 
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9. 


9. 


of RFC 3403 [8]. The security considerations described in these 
specifications apply to this specification as well. 


As with other domain object transforms, the EPP transform operations 
described in this document MUST be restricted to the sponsoring 
client as authenticated using the mechanisms described in sections 
2.9.1.1 and 7 of RFC 3730 [5]. Any attempt to perform a transform 
operation on a domain object by any client other than the sponsoring 
client MUST be rejected with an appropriate EPP authorization error. 
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